Modern Java in Action: Beyond the Monolith: Introduction to Project Jigsaw

This chapter covers:

Defining the goals of Project Jigsaw
Contrasting the Monolithic JDK vs. the Modular JDK
Understanding the limitations of Java 8 Compact Profiles
Identifying the architectural shifts in the Java 9 VM

For two decades, Java suffered from "Software Rust"—a slow decay where the platform became an unmanageable monolith. Every application, no matter how small, carried the weight of rt.jar, a massive 60MB+ file containing everything from GUI components to legacy CORBA classes.

1. The End of the Monolith

Project Jigsaw represents the most significant shift in Java's history. It shatters rt.jar into ~75 distinct modules. This isn't just about size; it's about Strong Encapsulation. By hiding internal APIs (like the infamous sun.misc.Unsafe), Java can finally evolve without breaking the world.

2. Why Compact Profiles Failed

Java 8 tried "Compact Profiles," but they were rigid, predefined subsets. Project Jigsaw replaces them with a truly extensible architecture where you use jlink to assemble only the modules your specific application needs.

TERMINAL bash — 80x24

> Ready. Click "Run" to execute.

QUESTION 1

What was the primary delivery mechanism for Java classes before Project Jigsaw?

module-info.class

rt.jar

jlink images

Compact Profiles

QUESTION 2

What is 'Software Rust' in the context of the JDK?

The deprecation of the AWT library.

Hardware degradation in server rooms.

The inability to evolve the JDK because internal APIs were accidentally exposed and used by developers.

Slow compilation times in Java 8.

QUESTION 3

How does the Java 9 Module System improve security?

It encrypts all .class files automatically.

It enforces strict encapsulation, preventing access to internal 'sun.*' packages by default.

It removes the need for a SecurityManager.

It forces all code to be signed.

QUESTION 4

Which tool is used to create a custom, minimal Java runtime image?

javac

jar

jlink

jmod

QUESTION 5

What is the relationship between a module and java.base?

java.base is optional and rarely used.

Every module must explicitly write 'requires java.base;'.

Every module depends on java.base automatically.

java.base was replaced by java.desktop.

Case Study: Microservice Optimization

Modularizing a Cloud-Native App

You are deploying a String-processing microservice to a Docker container. In Java 8, your Docker image was 200MB because it included the full JRE. You want to use Project Jigsaw to reduce this footprint.

1. Which specific module must your application at minimum depend on?

Solution:
The java.base module. It contains the fundamental classes like String, List, and the core Math libraries required by almost every Java program.

2. If your app uses JDBC, which module should you add to your module-info.java?

Solution:
You would add requires java.sql;. This informs the module system and jlink to include the SQL connectivity modules in the runtime.

3. Explain how jlink helps in this scenario compared to the old Monolithic JDK.

Solution:
With jlink, you can create a custom runtime image that excludes graphical libraries (java.desktop), XML processing, or CORBA. This reduces the attack surface and the storage footprint significantly.